PostgreSQL常用插件收集

hexdump -C 数据表文件 -- 查看表文件中数据。

pg_stat_statements

pgcompacttable -- 在减少锁的情况下，清理表和索引的老空间。

pg_reorg功能类似于vacuum full和cluster,但是它在执行过程中不产生锁,不会阻碍select和dml,在数据库维护过程中可以祈祷非常大的作用.

pg_repack--PostgreSQL中的表可能会由于MVCC特性而导致碎片化和膨胀，或者是因为大量的行被删除。这不仅会导致表中的空闲空间被占用，而且还会导致执行的sql语句效率不高。pg_repack是通过最流行的重新组织和打包表的办法来解决这个问题

pg_squeeze 表收缩插件：pg_squeeze is an open source PostgreSQL extension that enables automatic and transparent fixing of bloated tables https://www.cybertec-postgresql.com/en/products/pg_squeeze/

pgaudit--PostgreSQL有一个基础的语句日志功能。它可以设置log_statement =all参数来使用标准日志记录工具来实现。但这不足以满足大多数审计要求。企业部署的数据库特性之一就是针对用户交互/语句进行细粒度审计的功能。这是许多安全标准主要的遵从要求。PostgreSQL审计扩展(pgaudit)通过标准的 PostgreSQL日志记录工具提供详细的会话或对象审计日志记录。

pldebugger--对于使用PL/pgSQL编写存储过程的开发人员来说，这是一个必要的扩展。

plprofiler--这是一个很好的扩展，可以找到执行慢的代码位置。这是非常有用的，特别是在专用数据库（如Oracle到 PostgreSQL）的复杂迁移过程中，会影响应用程序的性能。这个扩展可以编写一份关于总体执行时间和表状态的报告，并提供每一行代码的清晰信息。这个扩展在PGDG repo中是不可用，需要从源码中构建它。

cstore_fdw-- PostgreSQL的列式存储扩展。

HypoPG--HypoPG是一个支持添加虚拟索引的扩展--也就是说，不实际添加索引。这有助于我们回答例如“如果x列上有索引，执行计划将会怎样”等问题。

orafce--实现了Oracle数据库中的一些功能。该功能在Oracle10g上得到了验证，该模块对于生产工作非常有用。

TimescaleDB--在这个IOT和互联设备的新世界中。对于时序数据需求越来越大。timescale可以将 PostgreSQL转换为可扩展时序数据进行存储。

pg_bulkload --将大量数据以非常高效和快速的方式加载到数据库中对您来说是一个挑战吗?如果这样的话，pg_bulkload可能会帮助你解决这个问题。

pg_pathman-- PostgreSQL10引入了分区。但是创建新的分区和维护现有分区，包括清除不需要的分区时需要手工操作，如果你想使用自动化的部分维护，可以看看pg_partman提供了什么功能。

wal2json--PostgreSQL具有与逻辑复制相关的内置特性，另外的信息被记录在WAL中，这将有助于逻辑解码。wal2json是一个流行的逻辑解码输出插件。还可以用于不同的用途，包括变化数据捕获。除了wal2json之外还有其他输出插件：PostgreSQL wiki中有一个简明的列表。

巡检类工具：

pgmetrics，GO写的一款PostgreSQL 多版本、健康监控指标采集、报告开源软件。https://github.com/rapidloop/pgmetrics

结合pgdash，可以实现被监控PG实例的可视化，指标值变更告警等。https://pgdash.io/

实时top类工具：

pg_center：Command-line admin tool for observing and troubleshooting Postgres.

pg_top：pg_top is 'top' for PostgreSQL. It is derived from Unix Top. Similar to top, pg_top allows you to monitor PostgreSQL processes.

pgfincore：将文件缓存到内存中

pgwarm：预热，两个差不多

pg_prewarm 集成于 contrib
pgfincore：https://github.com/klando/pgfincore

1)pgfincore

主要是利用 POSIX 的  posix_fadvise函数，pgfadvise_loader_file中可以看到它的调用，支持两种模式：POSIX_FADV_WILLNEED与POSIX_FADV_DONTNEED，posix_fadvise详细解释请看：http://linux.die.net/man/2/posix_fadvise。

文档没有提到 WILLNEED 会持续多久，影响范围多大，恐怕需要我们去读一下源代码才能更清楚。

看名字就知道，这个函数只是建议 OS 怎么做，最终还得OS说了算。

2)pg_prewarm

直接看利用系统缓存的代码，简单粗暴，但是最终哪些块能留住恐怕就不好说了。

并不是每个系统都支持 posix_fadvise，这时候 pg_prewarm 就会成为唯一选择。

可以看出，利用操作系统缓存来预热PG数据，都有一定的不可控性，并不能干涉最底层的动作，都是发出建议。